OpenSSH 9.9, publicada en septiembre de 2024, cerro una transición que llevaba años prometida: soporte nativo de criptografia post-cuantica hibrida en el intercambio de claves SSH. En agosto de 2025 ya tenemos un anio de rodaje, clientes actualizados en la mayoria de distribuciones serias, y bastantes empresas empezando a pensar en la migración. Este post recoge los pasos concretos que hemos dado en los VPS de jacarsystems.net y las decisiones que se evitan con un poco de planificacion.
Por que ahora y no dentro de cinco anios
La razon de migrar SSH a post-cuantica no es que un ordenador cuantico pueda romper tu conexión manana. Ni siquiera dentro de cinco anios. La razon es el ataque almacenar ahora, descifrar después. Un adversario que capture el tráfico de tu SSH hoy puede archivarlo y, cuando un ordenador cuantico capaz de romper Diffie-Hellman o ECDH aparezca, descifrar retroactivamente toda la sesion. Si en esa sesion hay contrasenas, secretos, claves API o datos sensibles que siguen siendo validos dentro de diez o quince anios, la captura de hoy sigue teniendo valor.
Este riesgo no aplica igual a todo el mundo. Para SSH de uso cotidiano a servidores de un hobby personal, la probabilidad de ser objetivo de almacenamiento selectivo es baja y el coste del ataque es alto. Para infraestructura corporativa, financiera, sanitaria, o cualquier uso donde circulen secretos con horizonte largo, el cálculo cambia. La recomendacion del NIST desde 2024 es migrar a post-cuantica en cualquier comunicación con datos sensibles a largo plazo, empezando ya.
Que trae OpenSSH 9.9 y 10.0
La novedad clave de OpenSSH 9.9 es el soporte nativo de ML-KEM-768, el estandar post-cuantico basado en Kyber de CRYSTALS seleccionado por el NIST. La implementación es hibrida: combina ML-KEM con X25519 en el intercambio de claves, de forma que la sesion es segura si al menos uno de los dos algoritmos resiste. Si ECDH cae manana porque aparece un ordenador cuantico, ML-KEM protege. Si se descubre un fallo en ML-KEM, X25519 protege. Esta redundancia es la caracteristica mas importante del modo hibrido.
El algoritmo concreto en OpenSSH se llama sntrup761x25519-sha512 desde 2020, y en 9.9 se anadio mlkem768x25519-sha256 como opcion recomendada. Ambos son hibridos y post-cuanticos. La diferencia es que sntrup761 esta basado en NTRU Prime, que no fue seleccionado como estandar NIST, mientras que ML-KEM 768 es el estandar oficial. Para migraciones nuevas, ML-KEM es la eleccion correcta.
OpenSSH 10.0 publicada en abril de 2025 ha hecho mlkem768x25519-sha256 el intercambio de claves por defecto cuando ambos extremos lo soportan. Esto significa que si actualizas servidor y cliente a 10.0, el modo hibrido se activa sin configuración adicional. La linea de log KEX algorithm: mlkem768x25519-sha256 confirma que la sesion esta protegida contra adversario cuantico.
La parte mas fácil: claves de host
Aunque el intercambio de claves ya es post-cuantico en OpenSSH 9.9, las claves de autenticación, es decir las claves de usuario y de host, siguen siendo clasicas. Esto es deliberado: el estandar para firmas post-cuanticas, ML-DSA basado en Dilithium, lleva menos tiempo en especificacion estable y OpenSSH todavia no lo soporta en rama principal. La decision del proyecto es migrar primero el intercambio de claves, donde el riesgo de almacenar ahora descifrar después es mayor, y migrar firmas cuando el ecosistema este maduro.
Esto tiene una implicacion práctica importante: las claves de host Ed25519 que ya tienes siguen siendo validas y apropiadas. No hay que regenerarlas. Cuando ML-DSA llegue a OpenSSH, probablemente en 2026, habra que anadir claves de host adicionales, no sustituir las existentes. La migración es aditiva, no disruptiva.
Pasos concretos de migración
El primer paso es actualizar OpenSSH a 9.9 o 10.0 en servidores y clientes. En Debian 13 Trixie, OpenSSH 9.9 esta en los repositorios por defecto. En Ubuntu 24.04 LTS llega via actualizacion de seguridad. En macOS, el OpenSSH integrado suele ir por detras; Homebrew ofrece una versión reciente. En Windows 11, OpenSSH integrado alcanzo 9.5 en la actualizacion 24H2 y 10.0 esta disponible en 25H1.
El segundo paso es ajustar la configuración del servidor para priorizar los algoritmos hibridos sin eliminar compatibilidad con clientes antiguos. En sshd_config anadimos una linea KexAlgorithms con la lista preferida al principio: mlkem768x25519-sha256 primero, luego sntrup761x25519-sha512 como fallback, luego curve25519-sha256 para clientes que aun no soporten PQC. Esto permite que los clientes modernos usen PQC automaticamente y los antiguos sigan conectando con ECDH.
El tercer paso es probar que la sesion hibrida funciona realmente. Desde un cliente moderno, ssh -v servidor y buscar la linea KEX algorithm en los logs del cliente. Tiene que mostrar mlkem768x25519-sha256. Si muestra curve25519-sha256, alguno de los dos extremos no soporta PQC y la sesion es solo clasica. La diferencia es silenciosa: la conexión funciona igual, el usuario no nota nada, pero la protección post-cuantica no esta activa.
Que romper y que no romper
El riesgo principal de una migración mal hecha es dejar a clientes antiguos sin acceso. OpenSSH anteriores a 8.5 no soportan ni sntrup761 ni ML-KEM. Si el sshd_config exige solo algoritmos PQC, esos clientes no pueden conectar. La configuración recomendada incluye siempre un fallback clasico, al menos curve25519-sha256, hasta que se haya verificado que todos los clientes estan actualizados.
Otra trampa es la configuración automática de sistemas que generan sshd_config desde un gestor de configuración. Ansible, Puppet y Chef pueden tener plantillas con KexAlgorithms heredadas de hace tres anios que sobreescriben la configuración sin avisar. He visto varias instancias donde se actualizo OpenSSH pero el playbook seguia imponiendo la lista antigua de algoritmos, desactivando el soporte PQC sin que nadie lo notara. La revision del estado real con ssh -Q kex en el servidor es la verificacion definitiva.
Un tercer punto de atención son los bastion y jump hosts. Una sesion que atraviesa dos saltos SSH solo es post-cuantica si cada salto lo es. Si el bastion corre OpenSSH 8.9 aunque el servidor final tenga 10.0, la primera conexión al bastion no esta protegida contra adversario cuantico y el usuario se lleva la falsa impresion de estar protegido. La migración tiene que cubrir toda la cadena.
Impacto en rendimiento
El intercambio de claves PQC hibrido es mas caro que el clasico, pero solo en el handshake inicial. Una vez establecida la sesion, la criptografia simetrica que protege los datos no cambia. La diferencia en el handshake es entre 5 y 15 ms adicionales en una maquina moderna, lo que es imperceptible para sesiones interactivas. Para herramientas que abren cientos de conexiones SSH por segundo, como backups masivos o Ansible a gran escala, el coste agregado puede ser visible y conviene medir.
El tamanio del handshake si aumenta de forma notable. ML-KEM 768 incluye claves publicas de 1184 bytes, frente a los 32 bytes de X25519. Un handshake hibrido envia unos 2 KB mas que uno clasico. En redes de alta latencia o con MTU pequeña, esto puede requerir algun paquete extra. En la práctica esto nunca ha sido problema en mis pruebas, pero conviene saberlo si se conecta desde redes satelitales o moviles en zonas con mala cobertura.
Verificacion final
Tras la migración, la verificacion tiene tres componentes. Primero, lista de kex soportados por el servidor con ssh -Q kex; debe incluir mlkem768x25519-sha256. Segundo, captura de un handshake real con ssh -v y verificacion de que KEX algorithm muestra el algoritmo hibrido. Tercero, auditoria periodica del sshd_config para detectar cambios accidentales por otros procesos de configuración.
Un detalle que me gusto implementar es un test automatizado en el pipeline de CI que revisa mensualmente que los servidores exponen el intercambio hibrido. Es un script de cinco lineas que intenta conectar forzando solo mlkem768 y falla si el servidor no lo acepta. Asi cualquier cambio accidental se detecta pronto, no cuando alguien audita manualmente seis meses después.
Cuando compensa
Mi regla práctica es que la migración a SSH hibrido es razonable para cualquier servidor con información valiosa a largo plazo. Servidores de produccion, bastion corporativos, jump hosts a bases de datos, repos Git con código propietario, deben migrar cuanto antes. El coste es unos minutos de configuración y un pequeño riesgo de romper clientes antiguos, que se mitiga con la lista de fallback. La ganancia es protección contra una amenaza que crece cada anio.
Para servidores personales, homelab y sistemas que nunca portan datos sensibles, la urgencia es menor. Pero como la actualizacion es barata y el efecto es solo positivo, no hay razon para no migrar también. La resistencia mas comun que encuentro es la inercia, no un cálculo racional.
Como pensar la decision
La criptografia post-cuantica no es un tema abstracto para 2040, es una transición concreta que esta pasando ahora. OpenSSH es probablemente el servicio mas critico en infraestructura donde la transición es mas fácil y menos disruptiva. Si el equipo ya tiene OpenSSH 9.9 o 10.0, anadir una linea al sshd_config no es trabajo, es higiene. Dejar esa linea sin anadir es exactamente el tipo de deuda técnica silenciosa que explota cinco anios después cuando ya no hay tiempo de arreglarla.
Lo que me parece educativo de esta migración es que introduce en la rutina operativa el concepto de algoritmo hibrido. Durante los próximos anios, otros protocolos haran transiciones similares: TLS, IPsec, VPN. Los detalles cambian, pero el patron es el mismo: adoptar el nuevo algoritmo en modo hibrido, verificar que funciona, eliminar el clasico solo cuando la compatibilidad este asegurada. SSH es un buen sitio para practicar ese patron ahora que es barato, antes de tener que aplicarlo a toda la pila de red a la vez.
La advertencia honesta es que todavia quedan piezas sin resolver. Las firmas post-cuanticas en SSH no llegaran antes de 2026. Las claves FIDO en llaves hardware no soportan PQC por hardware. Las herramientas de auditoria aun no detectan bien si una sesion es hibrida. Esto no invalida la migración hoy, pero si subraya que la transición completa es un proceso de varios anios, no un evento. Empezar por el intercambio de claves es el paso lógico y la recompensa por hacerlo es desproporcionadamente grande respecto al esfuerzo.
